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(54) Event messages communiction between a client and a peripheral device in a computer 
network 



(57) A method for communicating an event mes- 
sage between at least one client (12) operatively con- 
nected to a peripheral device (1 0), the peripheral device 
being adapted to execute an event when selected by a 
user or a client, includes maintaining a table of event 
descriptors in the peripheral device (58, 60, 62, 64, 68, 
70, 72, 74), selectively adding entries to the table in re- 



sponse to receiving a preselected add event descriptor 
request from a connected client (14, 16, 18, 20, 22, 24, 
26, 28, 30, 34), selectively deleting entries from the table 
in response to receiving a preselected delete event de- 
scriptor request from a connected client (38, 40, 42, 44, 
46, 48, 50, 52, 54, 56), and the user selecting an entry 
from said table of event descriptors for executing the se- 
lected event (84, 90, 92, 94). 
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Description 

[ 0001 ] The present invention generally relates to a 
method for communicating an event message between 
one or more client computers operatively connected to 5 
a peripheral device, and more particularly to a method 
for adapting the peripheral device to execute an event 
when selected by a client computer or a user. 

[ 0002 ] It is common for a number of client computers 
to be connected to more than one peripheral, such as a io 
printer and/or a scanner. This arrangement allows a 
number of client computers to share the services of the 
printer and/or the scanner. Such client computers can 
be personal computers or other computers and will be 
referred to herein simply as a client. It is becoming more is 
popular to use a multifunction peripheral (MFP) to com- 
bine the functions of these peripherals into a single pe- 
ripheral. As a result, the use of the MFP devices are be- 
coming more sophisticated, creating the need for more 
efficient communications between the MFP device and 20 
the clients. 

[ 0003 ] One prior method of input peripheral event 
communication involved polling and sending simple but- 
ton press notifications. However, polling was inefficient 
because it used the communication bandwidth con- 25 
stantly rather than only when needed. There was also 
a tradeoff between responsiveness and increased 
bandwidth use because a prompt response to the user 
would require frequent polling, which made other com- 
munication, such as scanning or printing, take longer. 30 
[ 0004 ] Another approach has involved adapting the 
input peripheral to allow the user to select the destina- 
tion, and then sending the input data directly to that cli- 
ent computer. Another problem involved with this ap- 
proach was that the client computer often needed to per- 35 
form various setup steps before it was ready to receive 
the data. Furthermore, it often needed additional user 
input to route the data to the desired destination. Al- 
though the input could be performed at the client com- 
puter, the user was still required to input data in two dif- 40 
ferent places. Alternatively, the input could be per- 
formed at the peripheral, but this required the peripheral 
to know all possible actions that the client computer 
might want to take with the data, which made it very dif- 
ficult to add new functions to client computer software 45 
because of the necessity to change the peripheral at the 
same time. 

[ 0005 ] Accordingly, it is an object of the present inven- 
tion to provide an improved method for more efficient 
communications of an event message between a pe- 50 
ripheral device and a client connected to the network. 
[ 0006 ] It is a further object of the present invention to 
provide an improved method in which the user is able 
to complete the entire input task atthe peripheral device. 
[ 0007 ] The present invention provides a method for 55 
communicating an event message between one or more 
clients operatively connected to a peripheral device, and 
more particularly to a method for adapting the peripheral 



device to execute an event selected by a client or a user. 
The user can complete the entire input task at the pe- 
ripheral device. 

[ 0008 ] In accordance with this invention, there is pro- 
vided a method for maintaining a table of event descrip- 
tors in the peripheral device, selectively adding entries 
to the table in response to receiving a preselected add 
event descriptor request from a connected client, selec- 
tively deleting entries from the table in response to re- 
ceiving a preselected delete event descriptor request 
from a connected client, and consisting of a user select- 
ing an entry from said table of event descriptors for ex- 
ecuting the selected event. 

[ 0009 ] Other objects, features and advantages will 
become apparent upon reading the following detailed 
description, in conjunction with the attached drawings, 
in which: 

FIGURE 1 is a schematic diagram of an input pe- 
ripheral/client network architecture in which the 
present method is implemented; 

FIG. 2 is a flowchart illustrating the method for se- 
lectively adding entries to the table of event descrip- 
tors step of the present invention; 

FIG. 3 is a flowchart illustrating the method for se- 
lectively deleting entries from the table of event de- 
scriptors step of the present invention; 

FIG. 4 is a flowchart illustrating the method for the 
client to download entries from the table of event 
descriptors; 

FIG. 5 is a flowchart illustrating the method for the 
client to upload entries to the table of event descrip- 
tors; and, 

FIG. 4 is a flowchart illustrating the method in which 
a user can select an entry from the table of event 
descriptors of the present invention. 

[ 0010 ] Broadly stated, the present invention is direct- 
ed to a method and system for communicating event 
messages between at least one client operatively con- 
nected to a peripheral device. The method allows the 
user to complete the entire input task at the peripheral 
device. The peripheral device is adapted to maintain a 
table of event descriptors, and is also adapted to add 
and delete entries in the table in response to a prese- 
lected event descriptor request from a connected client. 
In addition, the peripheral device is adapted to allow a 
connected client to download and upload entries onto 
the table. Lastly, the peripheral device is adapted to al- 
low a user to select an entry from the table for executing 
the selected event. 

[ 0011 ] Turning now to FIG. 1 , a schematic diagram of 
an input peripheral/client network architecture is shown, 
and illustrates the way in which the client computers are 
connected for the implementation of the present inven- 
tion. A peripheral device, such as a multifunction periph- 
eral (MFP) 1 0, may be connected to a plurality of clients 
12 (two shown) to exchange communications of event 
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messages. The MFP 1 0 preferably maintains a table of 
event descriptors. This table of event descriptors is a list 
of entries from the clients 1 2, with each entry comprising 
a string of characters that constitutes a list of parameters 
that the clients 12 need to execute the event. Each pa- 
rameter, separated with a semi-colon character, is con- 
structed as a keyword that names the parameter and an 
associated value defining the parameter. For example, 
an entry may have the following format: 
"KEYWORD1=value1 ; KEYWORD2=value2;". This for- 
mat gives the clients 1 2 maximum flexibility because pa- 
rameters of any length may be introduced without af- 
fecting the peripheral device. The only requirement is 
that the total string not exceed some reasonable maxi- 
mum length set by the peripheral device. 

[ 0012 ] FIG. 2 shows the steps involved in which the 
M FP 1 0 provides the clients 1 2 a way to add an entry to 
the table. A user can send input material from the pe- 
ripheral by having the client 1 2 add an entry to the table. 
For example, one way that the client 1 2 can add an entry 
is by using a software program located on the client. The 
client 12 will first construct an event descriptor string 
with all the information needed to complete an event 
message to be included in an add-event message (block 
1 4). For example, the string might specify that the event 
is a scan and that the input data should be delivered to 
a word processor located on client 12. The client 1 2 then 
sends this add-event message to the MFP 1 0, request- 
ing that the event be added (block 16). One way to send 
the add-event message, for example, is by using the Pe- 
ripheral Management Language (PML) protocol to SET 
an ADD-ENTRY management object to direct the MFP 
1 0 to add the entry to the table. It should be noted that 
this task may be accomplished by other protocols. It 
should also be noted that if there are more than one cli- 
ent 12 connected to the MFP 10, the MFP 10 must then 
keep track of which client 12 supplied each entry in order 
to send the add-event message back. After the MFP 1 0 
received the add-event message from the client 12 
(block 18), the MFP 10 checks for an available space in 
the table (block 20). If no available space exists in the 
table, the MFP 10 will send an error message to the cli- 
ent 12 (block 22), and concludes the subroutine (block 
24). When a space is available in the table, the MFP 10 
will try to determine whether there is a duplicate entry 
by trying to find the exact event descriptor string in the 
table (block 26). If a duplicate is not found, then the MFP 
1 0 adds the new entry to the table (block 28). The MFP 
1 0 next sends a success message to the client 1 2 as an 
indicator to the client of the successful completion of the 
input add-event message (block 30). This concludes the 
subroutine of adding entries to the table, and the MFP 
10 returns to an idle state and waits for the next event 
message (block 32). On the other hand, an error mes- 
sage will be sent to the client 12 when a space is not 
available (block 34), and concludes the subroutine 
(block 36). 

[ 0013 ] Similarly, FIG. 3 shows the steps involved in 



which the MFP 1 0 provides the clients 12 a way to delete 
an entry from the table. When a user wants to terminate 
the use of a peripheral or wants to shut down the client 
1 2 so that it can no longer process events, the client 1 2 
5 will remove the entry or entries from the table. The client 
12 will first construct an event descriptor string with the 
exact same string it added earlier to be included in an 
delete-event message (block 38). The client 12 then 
sends this delete-event message to the MFP 10, re- 
questing that the event be deleted (block 40). This again 
can be accomplished, for example, by using the PML 
protocol to SET a DELETE-ENTRY management object 
directing the MFP 10 to delete the entry from the table. 
After the MFP 10 received the delete-event message 
from client 12 (block 42), the MFP 10 then tries to locate 
a match of both the string and the client 12 in the table 
(block 44). The MFP 1 0 determines if such a match was 
found (block 46). The MFP 1 0 accordingly removes the 
entry from the table if a match was found (block 48), and 
may then send a success message to client 12 as an 
indicator to the client of the successful completion of the 
input delete-event message (block 50). Again, the MFP 
10 returns to an idle state and waits for the next event 
message since the subroutine of deleting entries from 
the table comes to a conclusion after the success mes- 
sage is sent (block 52). On the other hand, if the MFP 
1 0 was unable to find a match in the table, an error mes- 
sage is sent to the client 12 (block 54). An additional 
step for the client 1 2 to display the error message to the 
user may be included to keep the user informed of the 
status (block 56). 

[ 0014 ] FIG. 4 shows the steps involved in which the 
MFP 10 provides the clients 12 a way to download an 
entry or entries from the table. The client 12 first sends 
a download-request message to the MFP 1 0 (block 58). 
MFP 10 receives this download-request message 
(block 60), and accordingly sends the event descriptor 
strings for the requested download entries to the client 
12 (block 62). After client 12 receives the download 
event descriptor strings (block 64), the subroutine is 
concluded (block 66). 

[ 0015 ] FIG. 5 similarly shows the steps of the MFP 1 0 
providing the clients 1 2 a way to upload an entry or en- 
tries to the table. This time, the client 1 2 builds the event 
descriptor string or strings for the upload request entry 
or entries, and the string is to be included in a download- 
ed-request message (block 68). The client next sends 
this upload-request message to the MFP 1 0 (block 70). 
The MFP replaces the table entries with the new event 
descriptor string as requested (block 72), and concludes 
this subroutine (block 74). 

[ 0016 ] In accordance with another aspect of the 
present invention, FIG. 6 shows the steps involved in 
which the MFP 10 provides a user a way to select an 
entry from the table. The MFP 1 0 waits for the user to 
start the selection event process (block 76), which takes 
place when the user invokes an event selection mech- 
anism on the MFP 10. For example, a scanner or ascan- 
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capable MFP 10 might provide a "SCAN TO" button. 
When the user presses the button, the MFP 10 selects 
one entry from the table for display to the user. As a 
convenience to the user, it is more desirable to select 
the most recently used entry since this entry would most 
likely be the one that the user seeks. For example, each 
time the "SCAN TO" button is pressed, the MFP 10 ad- 
vances to the next entry in the table and displays it to 
the user. In this case, the MFP 10 shows the "name" 
portion of the "DISPLAY=name" parameter in the string 
(block 78). 

[ 001 7 ] The client 1 2 then provides a way for the user 
to choose or input a name that easily identifies the entry 
to the user, and waits for an input from the user (block 
80). The user may be given three choices for the input, 
specifically choices to move to next entry, select current 
entry, or cancel. If the user picks the choice to move to 
next entry, the MFP 10 shows the newly selected entry 
using the "DISPLAY=name" parameter in the string 
(block 82) and waits for a new user input (block 80). If 
the user chooses the input of cancel, the MFP 10 ig- 
nores the selection event process initiated earlier by the 
user (block 86), and concludes the select entry subrou- 
tine (block 88). When the user finally selects the entry, 
the MFP 1 0 sends the selection-event message with the 
complete event descriptor string necessary to execute 
the event back to the client 12 (block 90). The MFP 10 
stores this entry as the most recently used entry as an 
update for next time (block 92). The client 12 receives 
and acknowledges the selection-event message as re- 
quired by the underlying messaging protocol, such as 
the PML protocol. In the case of the PML protocol, a 
PML TRAP-REPLY message is sent by the client 12. 
The client 12 then executes the selection-event mes- 
sage, specifically executing the action indicated by the 
complete event string that was added to the selection- 
event message (block 66). After the execution, the sub- 
routine of selecting the entry is completed (block 68). 
[ 0018 ] From the foregoing description, it should be 
understood that an improved method for communicating 
event messages between at least client operatively con- 
nected a peripheral device has been shown and de- 
scribed which has many desirable attributes and advan- 
tages. The method adapts an input peripheral device to 
enable the user in completing the entire input task at the 
peripheral device, rather than dividing parts of the task 
between the peripheral device and the clients. 

[ 0019 ] While various embodiments of the present in- 
vention has been shown and described, it should be un- 
derstood that other modifications, substitutions and al- 
ternatives are apparent to one of ordinary skill in the art. 
Such modifications, substitutions and alternatives can 
be made without departing from the scope of the inven- 
tion, which should be determined from the appended 
claims. 

[ 0020 ] Various features of the invention are set forth 
in the appended claims. 



Claims 

1. A method for communicating an event message be- 
tween at least one client (12) operatively connected 

5 to a peripheral device (10), the peripheral device 
being adapted to execute an event when selected 
by a client or a user, said method comprising the 
steps of: 

io maintaining a table of event descriptors in the 

peripheral device (58, 60, 62, 64, 68, 70, 72, 
74); 

selectively adding entries to said table of event 
descriptors in response to receiving a prese- 
15 lected add event descriptor request from a con- 

nected client (14, 1 6, 18, 20, 22, 24, 26, 28, 30, 
34); 

selectively deleting entries from said table of 
event descriptors in response to receiving a 
20 preselected delete event descriptor request 

from a connected client (38, 40, 42, 44, 46, 48, 
50, 52, 54, 56); and, 

a user selecting an entry from said table of 
event descriptors for executing the selected 
25 event (84, 90, 92, 94). 

2 . The method according to claim 1 wherein each en- 
try contained in said table of event descriptors is a 
string of characters constituting a list of parameters 

30 needed for at least one client to execute the event 
message, each parameter is constructed as a key- 
word that names the parameter and an associated 
value defining the parameter, and each parameter 
is separated with a semi-colon character. 

35 

3. The method according to claim 1 wherein said se- 
lectively adding entries step further comprises the 
steps of: 

40 the client constructing an event descriptor 

string including all the information needed to 
complete the event message for an add-event 
message (14); 

the client sending said add-event message to 
45 the peripheral device (16); 

the peripheral device receiving said add-event 
message (18); 

the peripheral device sending an error mes- 
sage to client if the table is full (20, 22); and, 

50 the peripheral device locating the exact event 

descriptor string in the table of event descrip- 
tors if the table is not full (20, 26). 

4 . The method according to claim 1 wherein said se- 
55 lectively adding entries step further comprises the 

steps of: 

the client sending a download-request mes- 
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sage to peripheral device (58); 8. The method according to claim 1 , wherein said se- 

the peripheral device receiving said download- lectively deleting entries step further comprises 

request message (60); steps of: 

the peripheral device sending the download 



event descriptor strings with the requested 
download entries from said table of event de- 
scriptor to client (62); and, 
the client receiving the downloaded event de- 
scriptor strings (64). 

5 . The method according to claim 1 wherein said se- 
lectively adding entries step further comprises the 
steps of: 

the client builds event descriptor string for an 
upload-request message (68); 
the client sends said upload-request message 
to peripheral device (70); and, 
the peripheral device replacing event descrip- 
tor strings in said table of event descriptor with 
the requested download-request entries (72). 

6 . The method according to claim 1 , wherein said se- 
lectively deleting entries step further comprises 
steps of: 

the client constructing an event descriptor 

string including the exact event string added 

earlier for a delete-event message (38); 

the client sending said delete-event message 

to the peripheral device (40); 

the peripheral device receiving said delete- 

event message (42); 

the peripheral device locating the exact event 
descriptor string in said table of event descrip- 
tors (44); 

the peripheral device removing the entry from 
said table of event descriptors if said exact 
event string is found (46, 48); and, 
the peripheral device sending an error mes- 
sage to the client if said exact event string is 
not found (46, 54). 

7 . The method according to claim 1 wherein said se- 
lectively deleting entries step further comprises the 
steps of: 

the client sending a download-request mes- 
sage to peripheral device (58); 
the peripheral device receiving said download- 
request message (60); 

the peripheral device sending the download 
event descriptor strings with the requested 
download entries from said table of event de- 
scriptor to client (62); and, 
the client receiving the downloaded event de- 
scriptor strings (64). 



5 the client builds event descriptor string for an 

upload-request message (68); 
the client sends said upload-request message 
to peripheral device (70); and, 
the peripheral device replacing event descrip- 
70 tor strings in said table of event descriptor with 

the requested download-request entries (72). 

9 . The method according to claim 1 , wherein said step 
of a user selecting an entry further comprises the 

15 steps of: 

the user initiating a selection event process 
(76); 

the peripheral device displaying a most recently 
20 used name in the "DISPLAY=name" parameter 

contained within the entry descriptor string 
(78); 

the client providing a means to allow users to 
input a name of the entry (80); and, 

25 the peripheral device responding to said input 

name of the entry from the client (84). 

10 . A system for enabling the execution of events by a 
peripheral device, wherein the events are defined 

30 by selective event messages and wherein event 
messages can be requested by a user and at least 
one client operatively connected to the peripheral 
device, said system comprising: 

35 means for maintaining a table of event descrip- 

tors in the peripheral device (58, 60, 62, 64, 68, 
70, 72, 74); 

means in the connected client for selectively 
generating preselected add event descriptor 
40 requests for adding entries to said table of 

event descriptors (14, 16, 18, 20, 22, 24, 26, 
28, 30, 34); 

means in the connected client for selectively 
generating preselected delete event descriptor 
45 requests for deleting entries from said table of 

event descriptors (38, 40, 42, 44, 46, 48, 50, 
52, 54, 56); and, 

a user selecting an entry from said table of 
event descriptors for executing the selected 
50 event (84, 90, 92, 94). 
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